@mamico This is now working for us for our needs (as described in collective/volto-form-block#123). It is however a fairly big architectural change. Any comments on this approach? is it worth us finishing or there is no chance of getting this merged?

@mamico This is now working for us for our needs (as described in collective/volto-form-block#123). It is however a fairly big architectural change. Any comments on this approach? is it worth us finishing or there is no chance of getting this merged?

@JeffersonBledsoe @djay I don't have a clear opinion, but at first glance, it does seem that handling the form definition and data in a centralized way aligns less with the Plone/Volto model. Have you considered an alternative like volto-repeatable-content-block, or maybe I didn't fully understand, or it doesn't entirely cover your use case?

In any case, I would also check with @sneridagh and @robgietema, as they have been working extensively on the long-term rework of the product (collective/volto-form-block#110).

The usecase is a form in a slot. Our slots editor allows this. For instance a below content slot or a form in a footer.

It's not about what is the plone way to handle it. Is it a good idea to store form data in page and have that removed when the page is removed? Ir have the data not follow the form if it's moved from one page to another. I would argue not. I would argue that it's better to have a central control panel that lets you view the data collected by forms and remove or manage them with visibility.

But in any case the current PR does not choose to change the default of storing data in the page if the page is available. It only stores it centrally if the page is not available such as the case with slots.